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Abstract  -  An  important  principle  of  building  trustworthy  systems  is  to  rigorously  analyze  the 
critical  requirements  early  in  the  development  process,  even  before  starting  system  design. 
Existing  proof  methods  for  systems  of  communicating  processes  focus  on  the  bottom- up 
composition  of  component-level  specifications  into  system-level  specifications.  Trustworthy 
system  development  requires,  instead,  the  top-down  derivation  of  component  requirements  from 
the  critical  system  requirements.  This  paper  describes  a  formal  method  for  decomposing  the 
requirements  of  a  system  into  requirements  of  its  component  processes  and  a  minimal,  possibly 
empty,  set  of  synchronization  requirements.  The  Trace  Model  of  Hoare's  Communicating 
Sequential  Processes  (CSP)  is  the  basis  for  the  formal  method.  We  apply  the  method  to  an 
abstract  voice  transmitter  and  describe  the  role  that  the  EHDM  verification  system  plays  in  the 
transmitter's  decomposition.  In  combination  with  other  verification  techniques,  we  expect  that 
the  method  defined  here  will  promote  the  development  of  more  trustworthy  systems. 

Index  Terms  -  Automated  theorem  proving,  communicating  processes,  formal  specification, 
formal  verification,  process  algebras,  requirements  definition,  trusted  systems,  safety,  security. 


I.  Introduction 

A  critical  system  is  any  system  that  can  behave  catastrophically.  A  critical  requirement 
of  a  system  is  any  requirement  that  if  not  satisfied  can  result  in  catastrophic  behavior.  In 
security-critical  systems,  a  catastrophe  might  be  the  unauthorized  disclosure  of  information;  in 
safety-critical  systems,  it  might  be  the  uncontrolled  release  of  energy.  Most  critical  systems 
require  an  extremely  high  degree  of  assurance  that  they  meet  their  critical  requirements.1  In 
combination  with  more  conventional  verification  and  validation  techniques,  formal  methods 
can  help  attain  this  increased  level  of  assurance. 

An  important  step  in  applying  formal  methods  to  the  development  of  a  trustworthy 
system  is  to  specify  formally  its  critical  requirements.  Once  these  are  specified  and  the  design 
process  has  begun,  methods  are  needed  to  derive  lower-level  component  requirements  from 
these  critical  requirements.  Past  work  [1,2, 3, 4]  suggests  that  process  algebras,  such  as 
Hoare's  Communicating  Sequential  Processes  (CSP)  [5],  facilitate  the  formal  specification  of 
a  system's  critical  requirements.  Unfortunately,  existing  proof  methods  for  these  languages 
focus  on  the  bottom-up  composition  of  component-level  specifications  into  system-level 
specifications,  rather  than  a  top-down  derivation  of  component  requirements  from  the 
(critical)  system  requirements.  With  this  in  mind,  we  define  a  foimal  method  for 
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Throughout  this  paper,  a  system  is  viewed  as  a  network  of  communicating  components  (or  component 
processes).  A  system  is  considered  trustworthy  if  there  is  an  acceptably  high  probability  that  it  satisfies  all  its 
critical  requirements. 
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decomposing  requirements  of  a  system  into  requirements  of  its  component  processes  and  a 
minimal,  possibly  empty,  set  of  synchronization  requirements.  CSP  is  the  basis  for 
describing  the  functionality  of  systems;  the  Trace  Model  is  the  basis  for  reasoning  about 
properties  of  systems  described  in  CSP[6,7]. 

The  specification  and  decomposition  of  system  requirements  proceeds  in  successive 
stages  of  refinement  and  proof.  Figure  1  illustrates  the  three  layers  of  specification  required 
for  a  decomposition.  As  shown  in  the  highest  layer,  requirements  may  exist  that  cannot  be 
partitioned  completely  into  requirements  on  an  individual  component;  such  requirements 
involve  the  synchronized  behavior  of  two  or  more  components.  Since  these  synchronization 
requirements  are  typically  more  difficult  to  verify,  the  decomposition  method  promotes 
reducing  their  number  and  complexity  as  far  as  possible.  The  set  of  these  requirements  is 
minimal  if,  when  each  requirement  is  described  in  conjunctive  normal  form,  each  conjunct  of 
each  requirement  depends  on  the  behavior  of  two  or  more  components. 
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Figure  1.  System  Requirement  Decomposition 

Section  II  of  this  paper  compares  our  method  with  other  methods  based  on  similar 
goals.  Section  III  presents  an  overview  of  the  relevant  elements  of  the  Trace  Model  of  CSP, 
extends  the  CSP  notation  to  facilitate  hierarchical  decomposition,  and  refines  the  method 
discussed  above  based  on  the  model  described.  Section  IV  describes  in  detail  the  application 
of  the  method  to  an  abstract  voice  transmitter.  Finally,  Section  V  discusses  the  use  of  the 
EHDM  verification  system  [8,9]  to  check  mechanically  the  integrity  of  the  decomposition 
process,  both  in  general  and  as  it  was  used  in  the  decomposition  of  the  voice  transmitter. 
General  conclusions  of  this  effort  and  plans  for  future  research  are  also  presented.  Proofs  in 
the  main  body  of  the  paper  are  written  in  the  style  used  in  [10],  where  justifications  for  each 
proof  step  are  provided  as  hints  enclosed  in  curly  brackets.  The  complete  proofs  of  the 
theorems  used  in  this  paper  and  the  decomposition  of  the  voice  transmitter  using  EHDM  are 
documented  in  [11,12]. 

II.  Comparison  with  Related  Work 

Hoare's  work  on  CSP  [5,13]  and  Milner's  work  on  CCS  [14,15]  have  provided  the 
basis  for  many  of  the  methods  described  for  the  design  and  verification  of  concurrent 
systems.  Previous  comparisons  [6,16,17,18]  characterize  these  methods  by,  among  other 
things,  the  model  of  concurrency  used,  the  types  of  properties  provable,  and  the  structure  of 
systems  specifiable.  Due  to  the  wealth  of  work  done  in  this  area  we  restrict  our  comparison 
primarily  to  methods  based  on  CSP.  Rather  than  explicitly  describing  each  method  and 
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comparing  it  with  our  own,  we  describe  how  our  method  fits  into  the  previously  defined 
characterizations.  This  provides  an  implicit  comparison  with  much  of  the  previous  work  in  a 
relatively  short  amount  of  space.  We  also  compare  our  work  with  efforts  to  use  traces  for 
the  abstract  description  of  software  and  with  more  recent  work  not  included  in  the  past 
characterizations . 

A.  A  Family  of  CSP  Models 

Olderog  and  Hoare  [6]  describe  a  family  of  increasingly  sophisticated  models  for 
communicating  processes:  the  Counter  Model  [19,20],  the  Trace  Model  [7,21,22],  the 
Divergences  Model,  the  Readiness  Model  [19,23],  and  the  Failure  Model  [24,25,26]. 
Starting  with  the  least  sophisticated,  the  Counter  Model  involves  the  description  of  systems 
using  separate  channel  histories.  This  model  is  shown  to  deal  adequately  only  with  acyclic  or 
tree-like  networks  of  processes.  The  Trace  Model  allows  the  description  of  arbitrary 
networks  of  processes.  Both  the  Counter  Model  and  the  Trace  Model  can  specify  safety 
properties,2  but  neither  can  deal  adequately  with  diverging  processes.3  The  Divergences 
Model  suffices  to  reason  about  systems  that  may  diverge.  The  Readiness  and  Failure  Models 
are  required  to  reason  about  liveness  in  addition  to  safety.  More  recent  work  proposes  the 
use  of  algebraic  equations,  rather  than  traces,  to  describe  and  prove  properties  about  CSP 
[27]. 

Olderog  and  Hoare  prove  that  the  Trace  Model  is  sufficient  to  reason  about  safety 
properties  of  non-divergent  cyclic  networks  of  processes.  We  choose  this  model  for 
specifying  and  decomposing  system  requirements  as  a  balance  between  its  expressive  power 
and  the  complexities  involved  with  its  use.  For  example,  the  Counter  Model  makes  it  difficult 
to  specify  certain  relationships  of  values  transmitted  across  different  channels  due  to  the  fact 
that  channel  histories  are  recorded  separately.  The  Gypsy  Verification  Environment  [28,29] 
exhibits  this  same  difficulty.  Although  useful  for  the  verification  of  a  variety  of  concurrent 
applications,  Gypsy  has  a  number  of  limitations  on  the  form  of  the  specification  and 
implementation  of  concurrent  programs.  At  the  time  this  paper  was  written,  it  was  very 
difficult  to  specify  exit  conditions  of  the  form  "at  the  time  a  message  is  received  over  channel 

A,  the  history  of  channel  B  (distinct  from  A)  satisfies  property  P."  The  Trace  Model 
alleviates  this  problem  by  interleaving  the  individual  channel  histories  in  the  order  in  which 
the  communications  take  place. 

B.  Characteristics  of  Trace-Driven  Proof  Systems 

Hooman  [17]  and  Barringer  [18]  describe  a  number  of  characteristics  of  proof 
systems  for  networks  of  processes.  They  distinguish  between  proof  systems  based  on 
shared  variables  [17,30,31]  versus  those  based  on  message  passing,  e.g.,  most  systems 
based  on  CSP.  Our  method  requires  specifically  that  the  only  way  one  process  may 
communicate  with  another  process  is  through  the  transmission  of  messages  over  channels. 
Hooman  distinguishes  between  proof  systems  based  on  a  posteriori  verification  [32,33] 
versus  verification  as  part  of  the  design  process  [21,34,35].  Since  the  design  and 
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^  Safety  for  concurrent  processes  corresponds  to  partial  correctness  for  sequential  programs.  Intuitively,  safety 
properties  specify  that  some  condition  does  not  occur  whereas  liveness  properties  specify  that  some  condition 
will  occur. 

'J 

J  A  network  of  processes  is  non-divergent  if  all  recursion  is  guarded  and  there  is  no  possibility  of  the  network 
engaging  in  an  infinite  consecutive  sequence  of  hidden  events.  Note  that  while  all  terminating  processes  are  non- 
divergent,  not  all  non-divergent  processes  terminate. 
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implementation  of  nontrivial  systems  rarely,  if  ever,  proceeds  without  error  on  the  first 
attempt,  an  interactive  verification/development  process  is  an  important  part  of  our  method. 

A  proof  system  is  compositional  if  it  is  possible  to  derive  a  specification  of  a  system 
from  the  specification  of  its  components  without  knowledge  of  the  component's  internal 
structure.  The  verify-while-develop  paradigm  of  system  development  has  led  to  the  need  for 
compositional  proof  systems  [21,30,34,35]  versus  non-compositional  proof  systems 
[31,33].  We  introduce  a  special  compose  operator  to  CSP  allowing  the  description  of  a 
process  based  solely  on  the  external  channels  over  which  the  process  communicates.  By 
adapting  proof  rules  from  [5],  a  compositional  proof  method  is  defined  similar  to  the 
approach  used  by  van  de  Snepscheut  for  the  verification  of  hardware  designs  [10]. 
However,  unlike  previous  work,  our  method  emphasizes  the  decomposition  of  high-level 
requirements,  rather  than  the  composition  of  low-level  specifications. 

In  a  slightly  different  vein,  Bartussek  and  Pamas  [36]  and,  more  recently,  Parnas  and 
Wang  [37]  describe  the  use  of  trace  theory  for  the  abstract  specification  of  software  modules. 
Rather  than  reasoning  about  traces  of  communications,  as  does  the  Trace  Model  of  CSP,  this 
work  reasons  about  software  using  traces  of  procedure  calls.  McLean  extended  the  original 
work  by  providing  a  formal  foundation  for  specifying  software  requirements  using  traces 
[38]  and  defining  the  trace  semantics  of  a  simple  sequential  programming  language  [39]. 
This  provides  a  general  framework  for  specifying  and  verifying  sequential  program  behavior. 
In  combination  with  the  method  described  in  this  paper  for  decomposing  system-level 
requirements  into  component-level  requirements,  this  framework  may  be  useful  for 
specifying  and  verifying  the  critical  requirements  of  concurrent  software  systems. 

C.  Applications  to  Critical  Systems 

McCullough  [40]  and  Jacob  [1]  use  trace-based  methods  to  reason  about  the  multi¬ 
level  security  requirements  of  systems.  McCullough  introduces  the  notion  of  a  composable 
property  as  one  that  if  proven  of  the  components  of  a  systems,  is  true  of  the  system  as  a 
whole.  He  derives  a  composable  security  property,  called  restrictiveness,  and  demonstrates 
its  use  in  constructing  multi-level  secure  systems.  Unfortunately,  many  critical  requirements 
of  interest  may  not  be  composable  and,  therefore,  are  not  subject  to  the  methods  McCullough 
proposes.  Composability  applies  only  to  systems  composed  of  components  similar  enough 
that  the  same  critical  requirements  apply  to  all  components  and  to  the  system  as  a  whole.  The 
goal  of  our  method  is  to  tackle  the  more  general  problem  of  deriving  component  requirements 
from  arbitrary  system  requirements. 

Jacob  [1]  demonstrates  the  expressive  power  of  the  Trace  Model  of  CSP  by 
specifying  complex  multi-level  security  requirements  of  systems.  In  later  work,  Woodcock 
[41]  and  Jacob  [42]  describe  a  method  to  derive  an  implementation  from  a  specification  not  by 
intelligently  guessing,  but  rather  under  guidance  from  the  structure  of  the  specification. 
Woodcock's  approach  requires  stating  a  set  of  fairly  low-level  requirements  and  generating  an 
implementation  consisting  of  a  parallel  composition  of  processes,  each  component  of  which 
implements  a  requirement.  Jacob  discusses  problems  with  a  (possibly  nonterminating) 
method  of  generating  more  secure  designs  from  less  secure  designs  using  Woodcock's  basic 
approach.  Our  method  is  different  in  that  we  are  trying  to  derive  low-level  requirements  from 
a  given  high-level  requirement  and  (partial)  implementation.  We  do  not  assume  that  we  have 
the  freedom  to  choose  the  implementation  since  that  choice  may  depend  on  other 
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considerations,  e.g.,  the  required  non-critical  functionality  of  the  system  or  the  physical 
realization  of  the  system  in  hardware. 

III.  The  Decomposition  Method 

This  section  describes  an  iterative  seven-step  method  for  decomposing  system 
requirements.4  We  present  an  overview  of  relevant  elements  of  the  CSP  Trace  Model  and 
describe  a  (primarily  syntactic)  extension  for  constructing  systems  in  a  hierarchical  manner. 
In  the  course  of  this  discussion,  three  rules  are  introduced  that  are  used  to  justify  the 
definition  of  the  method.  We  use  standard  notation  where  possible  and  describe  CSP-specific 
notation  when  first  used.  We  assume  universal  quantification  of  variables  in  formulas  unless 
otherwise  indicated.  Readers  interested  in  a  summary  of  the  notation  used  or  other  details  of 
CSP  not  covered  in  this  paper  should  refer  to  [5]. 

A.  CSP  Preliminaries 

A  CSP  process  communicates  with  its  environment  through  named  communication 
channels.  The  Trace  Model  of  CSP  maps  a  process  to  an  alphabet  and  a  set  of  traces.  The 
alphabet  of  a  process  P,  denoted  aP,  specifies  all  events  in  which  P  is  permitted  to  engage. 
A  trace  of  a  process  is  an  observation  of  its  execution.  It  consists  of  a  finite  sequence  of 
events  in  which  the  process  has  engaged  at  some  moment  in  time.  The  set  of  all  traces  of  a 
process  P,  denoted  t races (P),  is  a  prefix-closed  nonempty  subset  of  aP*,  where  aP*  is  the 
set  of  all  finite  traces  formed  from  events  in  aP .5 

The  CSP  notation  allows  the  description  of  processes  using  a  variety  of  process 
constructors.  This  paper  primarily  deals  with  the  commutative  concurrency  operator,  II.  P  II 
Q  describes  a  process  executing  process  P  concurrently  with  process  Q.  P  II  Q  requires  P  and 
Q  to  participate  simultaneously  in  those  events  that  occur  in  both  aP  and  aQ.  Events 
occurring  in  aP  but  not  aQ  may  be  engaged  in  by  P  independently  of  Q.  Since  either  process 
of  a  concurrent  composition  may  itself  be  a  concurrent  process,  this  operator  supports  the 
description  of  arbitrary  networks  of  processes. 

Processes  executing  concurrently  communicate  through  channels.  A  communication 
event  is  a  special  type  of  event  described  by  a  pair  c.v.  The  alphabet  of  process  P  contains 
c.v  if  and  only  if  P  is  permitted  to  communicate  message  v  over  channel  c.  c  !  v  denotes  the 
output  of  value  v  on  the  channel  c;  c  ?  m  denotes  the  input  of  any  value  m  communicable  on 
the  channel  c.  These  operations  are  communication  events  defined  by 

Definition  1:  (c  !  v  -*  P)  =  (c.v  -*  P) 

Definition  2:  (c  ?  m  ->  P(m))  =  (c.n:aP  -*  P(n))) 

where  the  prefix  process  e  ->  P  describes  a  process  that  first  engages  in  the  event  e  and  then 
behaves  like  process  P;  and  the  choice  process  x:A  —>  P(x)  describes  a  process  that  chooses  a; 
from  A  then  behaves  like  P(x).  Although  the  CSP  notation  distinguishes  between  the  input 


4  Henceforth,  the  term  requirement  refers  to  the  statement  of  a  property.  The  term  specification  refers  to  the 
statement  that  a  system,  or  process,  satisfies  some  property. 

^  Traces(P)  must  be  prefix-closed  since  every  prefix  of  an  observation  of  P  must  also  be  an  observation  of  P.  The  set 
is  nonempty  since  the  empty  trace  is  a  valid  observation  of  every  process. 
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and  output  of  values  over  channels,  the  Trace  Model  uses  only  the  generic  dot  notation,  c.v, 
to  represent  communications  over  channels.  For  example, 

traces(c  !  v  -*  P)  =  {<  >}  U  {<c.v>  A 1 1 1 G  traces(P)} 
where  A  is  the  trace  append  operation. 

A  communication  of  message  m  over  channel  c  can  occur  between  two  processes 
running  concurrently  if  and  only  if  both  processes  have  the  communication  event  can  in  their 
alphabets  and  both  processes  simultaneously  engage  in  that  event.  That  is,  whenever  one 
process  outputs  a  value  onto  the  channel,  the  other  process  simultaneously  inputs  the  same 
value  from  the  channel.6  This  implies  that 

Definition  3:  ((c  !  v  -*  P)  II  (c  ?  m  -*  Q(m)))  =  (c.v  -»  P  II  Q(v)) 

where  c.v  occurs  in  aP  and  aQ.  If  only  one  process  in  a  system  has  a  communication  event 
in  its  alphabet,  then  that  process  may  engage  in  that  event  independently  of  any  other  process. 
To  simplify  the  theory  involved,  Hoare  assumes  that  at  most  two  processes  in  a  system  can 
access  the  same  communication  channel  and  that  communication  over  a  channel  occurs  in 
only  one  direction.  If  only  one  process  within  the  system  can  access  the  channel,  the  channel 
is  said  to  be  external',  if  two  processes  can  access  the  channel,  the  channel  is  said  to  be 
internal. 

A  requirement  in  CSP  is  viewed  as  a  set  of  traces.  Process  P  satisfies  a  requirement 
R,  denoted  P  sat  R,  if  and  only  if  R  contains  every  trace  that  may  occur  as  an  observation  of 

p. 


Definition  4:  (P  sat  R)  =  (traces(P)  R). 

Clearly,  a  requirement  is  satisfiable  by  some  process  only  if  it  contains  a  non-empty  prefix- 
closed  subset.  For  convenience  we  define  a  functional  notation  for  requirements 

Definition  5:  R(trl)  =  (trl  G  R) 
and  a  predicate  ValidTrace  as 

Definition  6:  ValidTrace(tr1 ,  P)  =  (trl  G  traces(P)). 

Then,  trivially, 

Lemma  1:  (P  sat  R)  iff  Vtrl.  (ValidTrace(tr1 ,  P)  =>  R(tr1 )). 

B.  Concurrent  Processes  and  Hiding 

The  Trace  Model  requires  relating  each  process  to  an  alphabet  and  a  set  of  traces. 
Since  our  goal  is  to  decompose  the  requirements  of  a  system  as  far  as  possible  into 
requirements  of  its  components,  it  is  helpful  to  define  the  alphabet  and  set  of  traces  of  a 
concurrent  process  in  terms  of  its  component  processes.  Clearly, 

Definition  7:  a(P  II  Q)  =  aP  U  aQ. 

The  valid  traces  of  a  concurrent  process  are  defined  as 


6  To  account  for  the  time  it  takes  to  transmit  information  over  physical  wires  we  can  associate  with  each  interface 
between  two  processes  an  additional  process  that  delays  transmissions  for  some  length  of  time.  For  ease  of 
exposition,  this  paper  does  not  consider  issues  regarding  transmission  delay;  for  details  see  [12]. 
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Definition  8:  ValidTrace(tr1 ,  P  II  Q)  =  (ValidTrace(tr1  PaP,  P) 

a  ValidTrace(tr1  PaQ,  Q) 
a  trl  <E(aP  UaQ)*), 

where  the  restriction  operator,  I',  takes  a  trace  and  a  set  of  events  and  returns  the  trace  with  the 
elements  not  in  the  set  removed.  Hoare  justifies  Definition  8  by  arguing  that  if  trl  G  traces(P 
II  Q),  then  every  event  of  trl  must  be  an  element  of  either  aP  or  aQ.  For  every  event  e  in  trl, 
e  G  aP  if  and  only  if  e  occurs  in  the  trace  of  P.  Likewise,  for  every  event  e  in  trl,  e  G  aQ  if 
and  only  if  e  occurs  in  the  trace  of  Q.  Therefore,  ( trl  P  aP )  G  traces!/3)  and  (trl  I'  aQ)  G 
traces! 0).  Definition  7  suggests  that  trl  must  be  an  element  of  (aP  U  aQ)*. 

Definition  8  requires  that  any  trace  of  a  concurrent  process  P  II  Q  include  every  event 
in  which  P  or  Q  engage.  The  visibility  of  the  communications  over  internal  channels  in  the 
traces  of  P  II  Q  reduces  the  amount  of  abstraction  possible  during  the  system  design  process. 
Hierarchical  design,  a  proven  method  for  managing  the  complexity  of  system  design  and 
verification,  requires  that  the  specification  of  a  component  be  based  solely  on  the  sequence  of 
external  communications  in  which  it  may  engage.  To  support  this,  we  define  the  compose 
operator,  denoted  l\l,  equivalent  to  the  CSP  concurrency  operator  except  that  the  internal 
communications  are  hidden;  consequently, 

Definition  9:  a(P  l\l  Q)  =  (aP  +  aQ) 

where  (a P  -s-  aQ)  =  (aP  U  aQ)  -  (aP  D  aQ).  Further,  we  define  a  new  operator,  f,  which 
extends  the  definition  of  P  to  operate  on  sets  of  traces,  as 

Definition  10:  A  f  S  =  {t  I  3f.  (f  e  A)  a  (f  PS  =  t)}. 

This  extension  allows  the  definition  of  the  traces  of  P  l\l  Q  in  terms  of  the  traces  of  P  1 1  Q  as 
Definition  11 :  traces(P  l\l  Q)  =  (traces(P  II  Q)  \  (aP  4-  aQ)). 

Concealing  communication  over  internal  channels  in  this  way  is  equivalent  to  that 
accomplished  by  the  trace  blend  operation  defined  in  [10]. 

Clearly  from  the  above  definitions,  the  alphabet  and  traces  of  a  compose  process 
contain  only  the  external  communication  events  in  which  the  process  may  engage.  Thus, 
each  valid  trace  of  a  compose  process  corresponds  to  some  valid  trace  of  the  related 
concurrent  process  as  follows: 

Rule  1:  ValidTrace(tr1,  P  l\l  Q) 

3tr2.  (ValidTrace(tr2,  P  II  Q) 

a  trl  =  (tr2  P  (aP  +  aQ))) 

Proof: 

ValidTrace(tr1 ,  P  N  Q) 

=  {Definition  6} 

trl  e  traces(P  l\l  Q) 

=  {Definition  11} 

trl  Gtraces(P  II  Q)  t  (aP  -  aQ) 

=  {Definition  10} 

trl  e  {t  I  3  tr2.  (tr2  e  traces(P  II  Q)  a  t  =  (tr2  P  (aP  4-  aQ)))} 
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->  {Definition  6} 

3  tr2.  (ValidTrace(tr2,  P  II  Q)  a  trl  =  (tr2  I'  (aP  +  aQ))) 

End  of  Proof. 

Note  that  the  compose  operator  is  just  a  convenient  notation  for  what  could  be  defined  using 
concealment  in  Hoare's  CSP.  For  example, 

(P  N  Q)  =  ((P  II  Q)  \  (aP  D  aQ)) 

where  the  CSP  concealment  operator,  \,  is  used  to  hide  all  communications  over  internal 
channels. 

As  mentioned  previously,  use  of  the  Trace  Model  requires  showing  that  the 
application  of  interest  is  non-divergent.  Divergence  arises  from  unguarded  recursion.  A 
recursion  of  the  form  \iP.F(P)  is  guarded  if  F (P)  starts  with  at  least  one  event  prefixed  to  all 
recursive  occurrences  of  P.  Divergence  can  also  arise  from  the  hiding  of  events  as  is 
accomplished  through  the  use  of  the  compose  operator.  Any  process  that  can  engage  in  an 
infinite  consecutive  sequence  of  hidden  events  is  divergent.  In  the  case  of  a  compose 
process,  divergence  leads  to  infinite  internal  chatter.  Hoare  defines  a  theory  for  reasoning 
about  divergent  processes.  From  this  theory  we  have  defined  a  method  for  stating 
requirements  on  component  processes  sufficient  to  guarantee  non-divergence  of  a  system 
[12].  This  is  a  fairly  mechanical  process  and  is  performed  in  isolation  from  the  requirement 
decomposition  process;  we,  therefore,  do  not  further  consider  issues  of  divergence  in  this 
paper. 

C.  Decomposing  System  Requirements 

We  are  now  able  to  state  and  prove  the  primary  inference  rules  for  decomposing 
requirements  of  a  compose  process.  The  first  reduces  the  problem  of  proving  requirements 
of  a  compose  process  to  proving  requirements  of  a  concurrent  process: 

Rule  2:  ((P  II  Q)  sat  R 

a  V  trl .  (ValidTrace(tr1 ,  P  N  Q) 

=>  3  tr2.  (ValidTrace(tr2,  P  II  Q) 
a  (trl  =  tr2  P  (aP  aQ)) 
a  (R(tr2)  =>  R(tr2  P  (aP  aQ)))))) 

=>  (P  l\l  Q)  sat  R 

Proof: 

(P II  Q)  sat  R 

a  V  trl .  (ValidTrace(tr1 ,  P  l\l  Q) 

=>  3  tr2.  (ValidTrace(tr2,  P  II  Q) 
a  (trl  =  tr2  P  (aP  4-  aQ)) 
a  (R(tr2)  =*  R(tr2  P  (aP  4  aQ))))) 

->  {Lemma  1} 

V  trl .  (ValidTrace(tr1 ,  P  N  Q) 

=>  3  tr2.  (R(tr2)  a  (trl  =  tr2  P  (aP  +  aQ)) 

a  (R(tr2)  =>  R(tr2  P  (aP  +  aQ))))) 

=  {Lemma  1} 

(P  N  Q)  sat  R 

End  of  Proof. 
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The  hypothesis  of  this  rule  requires  proving  properties  about  the  requirements  of  a  concurrent 
process.  The  following  inference  rule  reduces  the  problem  of  proving  requirements  of  a 
concurrent  process  to  proving  requirements  of  its  components: 

Rule  3:  ((P  sat  S)  a  (Q  sat  R) 

a  V  trl .  (ValidTrace(tr1 ,  P  II  Q) 

=*> ((S(tr1  P aP)  => S(tr1 ))  a  (R(tr1  I'aQ)  =>  R(tr1 )) 
a  ((S(trl)  a  R(tr1 ))  =>T(tr1))))) 

=>(P  II  Q)  satT 

Proof: 

(P  sat  S)  a  (Q  sat  R) 
a  V  trl .  (ValidTrace(tr1 ,  P  II  Q) 

=>((S(tr1  I'  oP )  =>  S(tr1 ))  a  (R(tr1  I'aQ  )  =>  R(tr1 )) 
a  ((S(trl)  a  R(tr1 ))  =>T(tr1)))) 

->  {Definition  8} 

V  trl.  ValidTrace(tr1,  P  II  Q) 

=^> (ValidTrace (trl  I'aP,  P)  a  ValidTrace(tr1  I'aQ,  Q) 
a  (P  sat  S)  a  (Q  sat  R)  a  (S(tr1  I'  aP )  =>  S(tr1 )) 
a  (R(tr1  I'aQ )  =>  R(tr1 ))  a  ((S(tr1 )  a  R(tr1 ))  =*  T(tr1 ))) 

->  {Lemma  1} 

V  trl .  ValidTrace(tr1,  P  II  Q) 

=> (S(tr1  I'aP  )  a  R(tr1  I'aQ)  a  (S(tr1  I'aP  )  ^S(trl)) 
a (R(tr1  I'aQ)  =>  R(tr1 ))  a  ((S(trl)  a  R(tr1 ))  => T(tr1 ))) 

=  {Lemma  1} 

(Pll  Q)satT 
End  of  Proof. 

Rules  1,  2,  and  3  form  the  basis  of  our  method  for  decomposing  system 
requirements.  Although  relatively  easy  to  prove,  they  encompass  the  conditions  sufficient  for 
justifying  the  method.  The  following  describes  and  justifies  the  method  using  these  rules: 

1 .  Describe  the  architecture  of  the  system  as  a  composition  of  processes  that  can  be  arranged 
in  a  binary  tree  P;p  for  0  <i  <  n  and  0  <j  <  2lhI .  Define  the  alphabet  of  the  system  as  the 
set  of  external  communication  channels,  and  only  those  communication  channels,  over 
which  the  system  is  permitted  to  communicate. 

This  step  requires  describing,  as  a  binary  tree,  that  part  of  the  system  architecture  of 
interest.7  Each  non-leaf  vertex  of  the  tree  is  a  process  representing  the  composition  of  its  left 
son  and  its  right  son.  Therefore,  each  subtree  represents  a  subsystem  of  the  entire  system. 
The  root  of  the  tree,  Pop,  represents  the  system  as  a  whole.  The  tree  need  not  be  complete,8 
but  if  a  vertex  has  one  son  then  it  must  have  both  sons.  Later  refinement  of  the  architecture 


7  Arranging  the  processes  in  the  form  of  a  binary  tree  is  done  solely  for  the  purpose  of  easing  the  statement  of  the 
method.  This  method  is  applicable  to  any  network  of  communicating  processes  that  is  constructed  with 
unidirectional  two-process  channels, 
o 

°  The  binary  tree  Pjj  is  complete  if  every  vertex  of  depth  less  than  n-1  has  both  a  left  son  and  a  right  son,  and  every 
vertex  of  depth  n-1  is  a  leaf.  The  depth  of  a  vertex  v  is  the  length  of  the  path  from  the  root  to  v. 
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specified  in  this  step  requires  the  straightforward  application  of  Steps  1  through  7  to  the  new 
part  of  the  architecture. 

2 .  Specify  the  necessary  requirements  of  the  system  in  the  form  P0  0  sat  R0,o. 

The  system  specification  is  stated  as  a  requirement  R00  of  P0,o-  Subsequent 
decomposition  will  result  in  a  requirement  R,j  for  each  process  P,j  of  the  system. 

->  For  0  <  i  <  n  and  0  <  j  <  2n~  1 ,  let  SR/j  be  the  derived  synchronization  requirement  for 
Pjj,  defined  as  true  initially.9  Traverse  the  tree  in  a  breadth-first  manner.  At  each  non¬ 
leaf  vertex  Pip  perform  the  following  steps: 

3.  Define  the  alphabets  of  Pi+ip  and  Pi+i?j+i-  Reduce  the  specification  of  the  compose 
process  Pj  j  to  the  specification  of  the  concurrent  process  (Pi+i,2j  H  Pi+uj+i)  by  proving  the 

Compose  Restriction  Condition, 

Ri,j(tr1 )  => Rj,j  (trl  PaPy). 

Definition  9  requires  that  the  alphabets  of  the  sons  of  P,  -n  /V/,2,  and  Pi+ijj+i, be 
defined  such  that  their  symmetric  set  difference  equals  the  alphabet  of  P,  -r  Under  these 
restrictions,  Pjj  sat  Rtj  follows  from  the  conditions 

1-  (Pi+1 ,2j  II  Pi+1,2j+l)  sat  Rj j 

2.  V  trl .  ValidT race(tr1 ,  Pj+i  2\  N  Pi+1 ,2j+1 ) 

=+  3tr2.(ValidTrace(tr2,  Pi+l,2j  H  Pi+1,2j+l) 
a  trl  =  (tr2  I'  (aPj+i  ;2j  +  aPj+i  ,2j+1 )) 
a  (Rj  j  (tr2)  =>  Rj  j  (tr2  P  (aPj+i  ,2j  +  «Pi+i  ,2j+1 )))) 

by  Rule  2.  The  second  condition  follows  from  Rule  1  and  the  proof  of  the  Compose 
Restriction  Condition.  The  first  will  be  decomposed  in  subsequent  steps.  In  this,  and 
subsequent  steps,  we  require  proof  of  stronger  conditions  than  necessary,  e.g.,  the  Compose 
Restriction  Condition,  so  as  to  proceed  without  any  specific  knowledge  about  the  valid  traces 
of  the  concurrent  process  Pi+ip  II  Pi+ipj+i ■  Requirements  that  depend  on  such  knowledge, 
referred  to  as  synchronization  requirements,  will  be  included  in  SR; jin  Step  7. 

4.  Derive  requirements  Ri+i?jJor  Pi+ip  and  Rj+igj+i  for  Pj+irl+i  with  the  goal  of  proving 
Pi+1,2j  II  Pi+I,2j+1  satisfies  Ru. 

This  is  the  first  attempt  to  determine  requirements  for  the  components  Pj+ijj  and 
Pi+i,2j+i ■  This  is  the  most  important,  and  often  the  most  difficult,  step  in  the  decomposition 
process;  the  better  the  determination  made  here,  the  less  work  that  is  required  in  subsequent 
steps.  It  is  important  to  make  the  requirements  as  weak  as  possible.  Although  finding  the 
weakest  requirements  may  be  difficult,  the  weaker  the  requirements  found,  the  less  that  will 
be  required  of  P/+  /  2/  and  Pj+uj+i  to  satisfy  Ri  r  This  maximizes  the  amount  of  freedom  in  the 
design  and  implementation  of  the  components  while  still  meeting  the  system-level 
requirements  defined. 

5.  Prove  the  Concurrent  Restriction  Condition, 


9  At  the  completion  of  this  method  the  combination  of  the  synchronization  requirements  SRjj  forms  the  minimal  set 
of  synchronization  requirements  discussed  in  the  introduction. 
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Ri+1 ,2j  (trl  r  otPi+1  2\ )  =>  Ri+1 ,2j(tr1 ) 
a  Ri  +  1  ,2j  +  1  (trl  I'  aPj  +  i  ,2j  +  1 )  =*  Ri  +  1 ,2j  +  1  (trl). 

If  this  proof  fails,  revise  the  requirements  so  that  Ri+igj  depends  only  on  the  events  in  the 
alphabet  of  Pi+j  2j  and  that  Ri+1 2j+i  depends  only  on  events  in  the  alphabet  of  Pj+j^j+i  and 
try  again. 

Once  the  component  requirements  are  formulated,  application  of  Rule  3  requires 
proving  the  condition 

ValidTrace(tr1,  Pj+1 ,2j  N  Pi+1,2j+l) 

=>  (Ri+1 ,2j  (trl  i  aPi+1 ,2j )  =>  Ri+1 ,2j(tr1 ) 

A  Ri+1 ,2j+1  (trl  r  ctPj+i  ,2j+1 )  =>  Ri+1 ,2j+1  (trl )). 

Proof  of  the  Concurrent  Restriction  Condition  is  sufficient,  though  not  necessary,  to  prove 
this  requirement.  If  it  cannot  be  proven,  Rj+igj  must  be  restricted  so  as  to  be  independent  of 

the  events  outside  of  aPi+1 2j,  and  Ri+12j+i  must  be  restricted  so  as  to  be  independent  of  the 
events  outside  of  a Pi+lt2j+1. 

6.  Attempt  to  prove  the  Conjunction  Condition, 

(Ri+1 ,2j  (trl)  a  Ri+1 ,2j+1  (trl ))  =*>Rij(tr1). 

If  successful,  continue  the  tree  traversal  to  the  next  vertex  at  step  3.  Otherwise,  specify  the 
weakest  condition,  C,  needed  to  complete  the  proof 

Application  of  Rule  3  requires  proving  that 

ValidTrace(tr1 ,  Pi+i,2j  H  Pj+1 ,2j+1 ) 

=>  ((Ri+1 ,2j  (trl )  a  R|+i  ,2j+l  (trl ))  =>  Rj,j(tr1 )). 

Proof  of  the  Conjunction  Condition  is  sufficient  to  satisfy  this  requirement.  If  it  is  provable, 
the  decomposition  at  the  current  vertex  is  complete;  in  this  case,  Pq  sat  R,  j  provided  that  Pi+i,2j 
sat  Ri+igj  and  P/+/.2/+  /  sat  Rj+ijj+i.  Otherwise,  Step  7  requires  deriving  a  condition  that 
allows  completion  of  the  proof.  As  in  step  4,  the  weaker  the  condition  found,  the  less  that 
will  be  required  of  Pi+i,2j  and  Pi+1>2j+]  to  satisfy  R,  r  The  weakest  condition  must  be  found  in 
order  to  guarantee  the  minimization  of  the  set  of  synchronization  requirements. 

7.  Describe  C  as  a  conjunction  of  simple  conditions  in  conjunctive  normal  form.  If  no 
conjunct  depends  solely  on  the  traces  of  either  Pj+igj  or  Pi+iy+i  then  conjoin  C  to  SRq  and 
continue  the  tree  traversal  to  the  next  vertex  at  step  3.  Otherwise,  conjoin  to  Rj+i:k  each 
conjunct  of  C  that  depends  only  on  the  traces  of  Pj+i,k  (for  k  =  2j  or  k  =  2j+l)  and 
continue  at  step  5. 

Requirements  that  depend  solely  on  the  behavior  of  one  component  process  are 
integrated  into  that  process's  specification  whenever  possible.  Describing  C  as  a  conjunction 
of  conditions,  each  captured  in  the  simplest  possible  context,  helps  ensure  that  no  requirement 
exists  that  could  be  stated  as  part  of  the  specification  of  one  of  the  component  processes. 
This,  in  turn,  maximizes  the  benefit  gained  from  the  decomposition  process  by  minimizing 
the  number  and  complexity  of  the  synchronization  requirements.  Those  requirements  that 
depend  on  two  or  more  component  processes  depend  on  specific  knowledge  about  the  valid 
traces  of  the  concurrent  process  and  are  added  to  SRjj. 


-  11  - 


D.  Assumptions 

The  above  method  reduces  the  problem  of  formally  verifying  the  requirements  of  a 
concurrent  system  into  two  separate,  simpler  problems:  verifying  that  the  system  components 
meet  their  derived  requirements  and  verifying  that  specific  combinations  of  those  components 
meet  any  derived  synchronization  requirements.  Of  course,  the  eventual  implementation  of 
the  components  of  the  system  and  their  interconnections  must  be  shown  to  satisfy  the 
assumptions  of  the  Trace  Model  of  CSP  on  which  our  method  depends.  In  summary,  these 
are  as  follows: 

1 .  The  only  way  a  process  can  communicate  with  another  process  executing  concurrently  is 
through  CSP-like  communication  channels;  no  shared  variables  are  permitted. 

2 .  Exactly  those  external  communication  channels  over  which  a  process  may  pass  data  are 
included  in  its  alphabet. 

3 .  At  most  two  processes  of  a  system  may  communicate  over  a  given  channel;  no  broadcast 
capability  exists.  If  the  channel  is  external,  exactly  one  process  in  the  system  must  have 
the  communication  events  associated  with  that  channel  in  its  alphabet.  If  the  channel  is 
internal,  exactly  two  processes  must  have  the  communication  events  associated  with  that 
channel  in  their  alphabets. 

4 .  Communication  over  a  given  channel  may  take  place  in  one  direction  only. 

5.  Any  assumptions  made  of  the  communication  media,  e.g.,  in  the  definition  of  a 
transmission  delay,  must  be  validated. 

Assuring  the  validity  of  these  assumptions  must  take  place  throughout  system  development. 

IV.  An  Example  Decomposition 

This  section  presents  a  description  of  the  verified  decomposition  of  an  abstract  voice 
transmitter  using,  as  a  guide,  the  iterative  seven-step  method  discussed  in  Section  III.  The 
example,  called  the  uASVT,  is  a  simplified  version  of  a  voice  terminal  specified  previously 
[2].  Although  the  notation  PL/  for  processes,  RLJ  for  component  requirements,  and  SRLj  for 
synchronization  requirements  is  convenient  for  describing  the  method  for  an  arbitrary 
application,  for  a  specific  application  this  notation  is  cumbersome.  Throughout  the 
specification  and  decomposition  of  the  uASVT,  we  use  mnemonic  names  for  processes  so 
that,  for  example,  the  requirements  for  the  process  uASVT  are  R,,asvt  and  SR,lASVT. 

A.  The  uASVT:  An  Informal  Description 

The  uASVT  allows  for  the  encrypted  or  plain  text  transmission  of  voice.  It  consists 
of  three  major  components  -  the  Voice  Processor,  the  Modem  Processor,  and  the  Comsec 
Module.  Figure  2  illustrates  the  two  external  interfaces,  Red  Channel  and  Black  Channel, 
and  the  three  internal  interfaces,  Voice  Modem,  Voice  Comsec,  and  Modem  Comsec,  through 
which  voice  transmissions  may  flow.  The  Red  and  the  Black  Channels  are  both  analog 
interfaces.  Conceptually,  the  Red  Channel  may  be  connected  to  telephone  sets  or  intercoms; 
the  Black  Channel  may  be  connected  to  radios  or  wireline  appliques. 
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Figure  2.  The  qASVT 

The  uASVT  has  a  control  panel  allowing  its  users  to  choose  between  the  cipher  or  the 
plain  mode  of  operation.  When  in  the  cipher  mode,  the  Voice  Processor  analyzes  outgoing 
transmissions,  the  Comsec  Module  encrypts  these  transmissions,  and  the  Modem  Processor 
codes  important  bits  and  modulates  the  resulting  bit  stream.  Transmissions  in  the  plain  mode 
are  processed  similarly  except  that  the  Comsec  Module  is  bypassed  so  that  information  is 
transmitted  through  the  Voice  Modem  channel  without  being  encrypted.  The  terminal  must  be 
clear  of  all  voice  transmissions  before  a  user  may  change  the  status  of  the  control  panel.  The 
key  used  for  encryption  is  pre-defined  by  the  system  and  never  changes.  A  user  can  receive 
transmissions  from  the  uASVT  only  if  he  has  access  to  a  receiver  that  inverts  the 
transformation  performed  by  the  terminal.  This,  of  course,  requires  access  to  the  decryption 
key.  The  details  of  the  uASVT  transformations  have  little  or  no  bearing  on  the  statement  of 
its  requirements  and  for  ease  of  exposition  are  omitted. 

The  uASVT  has  one  critical  requirement,  Red/Black  Separation.  More  specifically, 
all  information  transmitted  by  the  terminal  when  in  the  cipher  mode  of  operation  must  be 
Black,  encrypted,  data.  Thus,  the  only  way  for  the  uASVT  to  transmit  Red,  plain  text,  data 
is  when  the  control  panel  is  set  in  the  plain  mode.  Because  of  its  restricted  functionality,  the 
uASVT  serves  only  as  a  demonstration  of  the  method  discussed  in  this  paper  -  it  is  not 
intended  as  a  real-world  system.  The  practicality  of  this  method  and  its  demonstration  on  real 
systems  is  a  topic  of  future  research. 

B.  Specifying  pASVT  Architecture  and  Requirements 

1 .  Describe  the  architecture  of  the  pASVT  as  a  composition  of  processes  that  can  be 
arranged  in  a  binary  tree  Pq,  for  0  <  i  <  n  and  0  <  j  <2n~f  Define  the  alphabet  of  the 
pASVT  as  the  set  of  external  communication  channels,  and  only  those  communication 
channels,  over  which  the  pASVT  is  permitted  to  communicate. 


-  13  - 


The  uASVT  is  described  as  the  composition  of  three  CSP  processes,  VP  representing 
the  Voice  Processor,  CM  representing  the  Comsec  Module,  and  MP  representing  the  Modem 
Processor.  Let  uASVT  be  the  CSP  process  representing  the  terminal  as  a  whole.  Then, 

Definition  12:  ^ASVT  =  (VP  N  (CM  l\l  MP)). 

Figure  3  illustrates  the  uASVT  architecture  as  a  binary  tree  of  processes.  This  view  requires 
that  we  introduce  a  new  process  name  CMP,  for  Comsec  Modem  Processor,  representing  the 
composition  of  CM  and  MP. 

[aASVT  (P0  0  ) 


VP(P10)  CMP  (P ,  ,) 

v\ 

CM  (P2  2  )  MP  (P2  3 ) 


Figure  3.  uASVT  Architecture 

Define  M  to  be  the  set  of  all  possible  messages  communicable  over  the  message 
channels.  The  alphabet  of  the  uASVT  is  defined  to  be  those  communication  events  in  which 
it  is  permitted  to  engage  at  its  external  interface: 

Definition  13:  a(xASVT  =  {VPCtl.c,  RedChan.m,  BlackChan.m 

I  c  e  {cipher,  plain},  m  E  M}. 

The  message  channels  referenced  here  correspond  to  the  external  channels  described  in  the 
informal  description.  VPCtl  is  a  control  channel  that  notifies  the  uASVT  of  an  input  from  the 
control  panel;  these  inputs  can  be  either  cipher  or  plain  signifying  whether  the  teiminal  is  in 
cipher  mode  or  plain  mode. 

2.  Specify  the  necessary  requirements  of  the  system  in  the  form  uASVT  sat  RflASVT. 

Specifying  the  uASVT’s  critical  requirement,  Red/Black  Separation,  requires  that 
every  message  transmitted  while  in  the  cipher  mode  of  operation  be  encrypted.10  The 
Restriction  operator,  I',  provides  a  mechanism  for  specifying  properties  about  the  values 
transmitted  over  particular  channels  in  isolation  from  other  communications.  Specifying 
Red/Black  separation  requires  a  mechanism  stronger  than  this  to  determine,  given  an  arbitrary 
trace,  the  sequence  of  values  communicated  over  a  channel  when  in  the  cipher  mode  of 
operation.  We  define  an  abstract  mechanism  for  doing  this  since  it  will  be  useful  in  the 
specification  of  the  components  as  well  as  the  uASVT.  The  mechanism  is  based  on  a 
function  Filter, 


10 


Note  that  no  attempt  is  made  to  formally  specify  or  decompose  the  non-critical  functionality  requirements  in  this 
paper. 
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Definition  14:  Filter(tr1  ,set1  ,req1 ) 

=  if  trl  =  <  >  then  <  > 
elsif  Last(trl)  e  setl  a  req1(NonLast(tr1)) 
then  Append(Last(tr1), 

Filter(NonLast(tr1),set1  ,req1)) 
else  Filter(NonLast(tr1  ),set1  ,req1 ), 

where  <  >  denotes  the  empty  sequence,  Last  returns  the  last  element  of  a  sequence,  NonLast 
returns  all  but  the  last  element  of  a  sequence,  and  Append  appends  an  element  to  the  end  of  a 
sequence.  Intuitively,  Filter  returns  the  sequence  of  elements  of  trace  trl  that  are  in  set  setl 
such  that  the  sequence  of  events  leading  up  to  each  element  satisfies  requirement  reql . 

To  use  Filter,  we  define  a  function,  CipherMode,  that  determines  whether  the  terminal  is  in 
the  cipher  mode  after  an  arbitrary  sequence  of  communications  takes  place, 

Definition  15:  CipherMode(ctlch1)(tr1) 

=  if  trl  =  <  >  then  (InitialMode  =  cipher) 
elsif  Last(tr1 )  =  ctlchl  .c  then  (c=cipher) 
else  CipherMode(ctlch1  )(NonLast(tr1 )), 

where  InitialMode  is  the  position  of  the  control  panel  on  start-up  and  ctlchl  is  the  control 
channel  over  which  the  cipher/plain  mode  signals  are  sent.  Now,  if  chi: M  denotes  the  set  of 
all  communications  of  values  in  M  over  channel  chi, 

Filter(tr1,  ch1:M,  CipherMode(ctlchl)) 

returns  the  sequence  of  communications  over  chi  that  occur  in  trl  either  (1)  when  the  last 
value  sent  over  control  channel  ctlchl  was  cipher,  or  (2)  if  there  is  no  such  value,  when 
InitialMode  is  cipher. 

Red/Black  separation  requires  that  every  message  output  over  BlackChan  correspond 
to  the  proper  transformation,  including  an  encryption,  of  a  message  input  over  RedChan.  Let 
Key  be  the  key  used  by  the  uASVT  for  encryption  of  voice  and  the  functions  Analyze, 
Encrypt,  and  Modulate  be  the  functions  representing  the  transformations  performed  by  the 
Voice  Processor,  Comsec  Module,  and  Modem  Processor,  respectively.  Using  the  Filter 
function  as  described  above,  Red/Black  separation  is  captured  in  the  specification  of  the 
qASVT: 

Specification  1 :  pASVT  sat  R^asvt 

R(iASVt(F1  ) 

=  V  ml  .(BlackChan. ml  in  Filter(tr1  ,BlackChan:M, 

CipherMode(VPCtl)) 

=>3  m2.(RedChan.m2  in  Filter(tr1,RedChan:M, 

CipherMode(VPCtl)) 

a  Modulate(Encrypt(Analyze(m2),Key))  =  ml)), 
where  in  is  the  sequence  membership  symbol. 

C.  Decomposing  pASVT  Requirements:  The  First  Attempt 

The  top  level  CSP  specification  of  the  uASVT  composes  VP  with  (CM  l\l  MP). 
Although  a  full  analysis  requires  a  complete  traversal  of  the  tree  illustrated  in  Figure  3,  the 
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following  describes  only  the  decomposition  of  uASVT  into  two  components,  VP  and  CMP, 
where 


Definition  16:  CMP  =  (CM  l\l  MP); 

the  decomposition  of  CMP  proceeds  similarly.  Section  IV-E  describes  the  final  results  of  the 
full  decomposition  of  the  uASVT.  The  appendix  to  this  paper  presents  an  example  CSP 
implementation  of  VP,  CM,  and  MP. 

3.  Define  the  alphabets  of  VP  and  CMP.  Reduce  the  specification  of  the  compose  process 
pASVT  to  the  specification  of  the  concurrent  process  (VP  II  CMP )  by  proving  the 

Compose  Restriction  Condition, 

P/jASvt(T"I  )  =>  R,,ASVT(tr1 1  auASVT). 

The  alphabets  of  the  uASVT  component  processes  are  defined  as 

Definitions  17: 

aVP  ={VPCtl.c,  CMCtl.c,  RedChan.m,  VoiceComsec.m, 

VoiceModem.m  I  c  e  {cipher,  plain},  m  G  M}, 
aCM  =  {CMCtl.c,  MPCtl.c,  VoiceComsec.m, 

ModemComsec.m  I  c  G  {cipher,  plain},  m  G  M},and 
aMP  =  {MPCtl.c,  BlackChan.m,  ModemComsec.m, 

VoiceModem.m  I  c  G  {cipher,  plain},  m  G  M}. 

CM  is  notified  of  changes  in  the  control  panel  by  VP  through  the  CMCtl  channel.  Likewise, 
MP  is  notified  of  changes  in  the  control  panel  by  CM  through  the  MPCtl  channel.  The 
alphabet  of  CMP  follows  from  Definition  9  and  Definitions  17, 

Lemma  2:  aCMP  =  (aCM  4-  aMP). 

The  CSP  process  architecture  for  the  uASVT  is  shown  in  Figure  4. 


Figure  4.  uASVT  CSP  Architecture 


Proof  of  the  Compose  Restriction  Condition  requires  showing  that  the  truth  of  Ruasvt 
depends  only  on  the  occurrence  of  events  in  uASVT's  alphabet.  Towards  this  goal,  let  <  be 
the  trace  prefix  relation  such  that,  for  example,  tr2  <  trl  states  that  tr2  is  a  prefix  of  trl.  The 
following  lemma  states  sufficient  conditions  for  proving  that  the  value  returned  by  Filter 
depends  only  on  some  restricted  set  of  events: 
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Lemma  3:  ((setl  C  set2 

a  (V  tr2.  tr2  <  trl  =*  reql  (tr2)  =  reql  (tr2  r  set2))) 

=>  Filter(tr1  Pset2,  setl,  reql)  =  Filter(tr1,  setl,  reql)) 

Proof:  {by  mathematical  induction  on  the  length  of  trl} 

Base  Case:  {definition  of  1} 

Filter(<  >  P  set2,  setl ,  reql )  =  Filter(<  >,  setl ,  reql )) 

Induction  Step: 
trl  P  <  >  a  setl  C  set2 

a  (V  tr2.  tr2  <  trl  =>  (reql  (tr2)  =  reql  (tr2  I'  set2))) 
a  (V  tr2.  tr2  <  NonLast(tr1 )  =>  (reql  (tr2)  =  reql  (tr2  P  set2))) 

=>  Filter(NonLast(tr1)  Pset2,  setl,  reql) 

=  Filter(NonLast(tr1),  setl,  reql)) 

->  {Calculus} 
trl  P  <  >  a  setl  C  set2 

a  (V  tr2.  tr2  <  NonLast(trl)  =*  reql  (tr2)  =  reql  (tr2  P  set2)) 
a  Filter(NonLast(tr1)  Pset2,  setl,  reql) 

=  Filter(NonLast(tr1),  setl,  reql) 

Case:  Last(trl)  e  set2  {definition  of  P} 

(trl  P<>  a  req1(NonLast(tr1))  =  reql (NonLast(trl)  Pset2) 
a  Filter(NonLast(tr1  Pset2),  setl,  reql) 

=  Filter(NonLast(tr1),  setl,  reql)) 

-»  {Definition  14  of  Filter} 

Filter(tr1  Pset2,  setl,  reql)  =  Filter(tr1,  setl,  reql) 

Case:  Last(trl)  £  set2  {definition  of  P} 
trl  P  <  > 

a  Filter(tr1  P set2, setl , reql )=  Filter(NonLast(tr1), setl, reql) 

-»  {Definition  14  of  Filter} 

Filter(tr1  Pset2,  setl,  reql)  =  Filter(tr1,  setl,  reql) 

End  of  Proof. 

Since  the  only  place  that  P'1  is  referenced  in  Specification  1  of  R^asvt  is  as  a 
parameter  to  Filter,  the  Compose  Restriction  Condition  follows  from  Theorem  1  below.  We 
state  and  prove  this  theorem  after  proving  a  useful  lemma. 

Lemma  4:  {ctlchl  .cipher,  ctlchl  .plain}  C  setl 
=^CipherMode(ctlch1)(tr1  Psetl) 

=  CipherMode(ctlch1  )(tr1 ) 

Proof  {mathematical  induction  on  the  length  of  trl} 

Base  Case:  {definition  of  I'} 

CipherMode(ctlch1  )(<  >  P  setl )  =  CipherMode(ctlch1  )(<  >) 

Induction  Step: 

trl  P  <  >  a  {ctlchl  .cipher,  ctlchl  .plain}  Cl 
a  CipherMode(ctlch1)(NonLast(tr1)  Psetl) 

=  CipherMode(ctlch1)(NonLast(tr1)) 
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Case:  Last(trl)  e  {ctlchl .cipher,  ctlchl .plain} 

{Definition  15  of  CipherMode} 

CipherMode(ctlch1)(tr1  I'setl)  =  CipherMode(ctlch1)(tr1) 

Case:  Last(trl)  e  setl 

a  Last(trl)  {ctlchl  .cipher, ctlchl  .plain} 

{definition  of  1} 

trl  l'<>  a  (CipherMode(ctlch1)(NonLast(tr1  I'setl)) 

=  CipherMode(ctlch1  )(NonLast(tr1 ))) 

=  {Definition  15  of  CipherMode} 

CipherMode(ctlch1)(tr1  I'setl)  =  CipherMode(ctlch1)(tr1) 

Case:  Last(trl)  (£  setl 

a  Last(trl)  {ctlchl  .cipher, ctlchl  .plain} 

{definition  of  1} 

trl  l'<>  a  (CipherMode(ctlch1)(tr1  I'setl) 

=  CipherMode(ctlch1  )(NonLast(tr1 ))) 

=  {Definition  15  of  CipherMode} 

CipherMode(ctlch1)(tr1  I'setl)  =  CipherMode(ctlch1)(tr1) 

End  of  Proof. 

Theorem  1 : 

(Filter(tr1,  BlackChan:M,  CipherMode(VPCtl)) 

=  Filter(tr1  I'anASVT,  BlackChan:M,  CipherMode(VPCtl))) 
a  (Filter(tr1  ,RedChan:M,  CipherMode(VPCtl)) 

=  Filter(tr1  I'apASVT,  RedChan:M,  CipherMode(VPCtl))) 

Proof:  We  prove  the  first  conjunct;  the  proof  of  the  second  conjunct  proceeds  similarly.  By 
Lemma  3, 

(BlackChan:M  c  apASVT 
a  (V  tr2.  tr2  <  trl  (CipherMode(VPCtl)(tr2) 

=  CipherMode(VPCtl)(tr2  I'  anASVT)))) 

=*Filter(tr1  I'anASVT,  BlackChan:M,  CipherMode(VPCtl)) 

=  Filter(tr1,  BlackChan:M,  CipherMode(VPCtl)) 

->  {Definition  13  of  a(iASVT,  Lemma  4} 

Filter(tr1  I'anASVT,  BlackChan:M,  CipherMode(VPCtl)) 

=  Filter(tr1,  BlackChan:M,  CipherMode(VPCtl)) 

End  of  Proof. 

4.  Derive  requirements  Rypfar  VP  and  RcMpfor  CMP  with  the  goal  of  proving  VP  II  CMP 
satisfies  RflASVT- 

R[|  ASvt  states  that  every  message  transmitted  by  the  terminal  when  in  the  cipher  mode 
is  a  proper  transformation  of  some  message  received  by  the  terminal.  A  natural  requirement 
decomposition  is  to  require  that,  when  in  the  cipher  mode,  every  message  transmitted  by  a 
component  be  a  proper  transformation  of  some  message  received  by  the  component.  A 
proper  transformation  for  VP  is  to  Analyze  the  message;  a  proper  transformation  for  CMP  is 
to  Encrypt,  using  the  encryption  key  Key,  and  then  Modulate  the  message.  This  suggests  the 
following  specifications  for  VP  and  CMP,  respectively: 
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Specification  2:  VP  sat  RVp 

RVp(tr1)  =  V  ml.  (VoiceComsec.ml  in  Filter(tr1,  VoiceComsec:M, 

CipherMode(VPCtl)) 

=>  3  m2.(RedChan.m2  in  Filter(tr1 ,  RedChan:M, 

CipherMode(VPCtl)) 
a  Analyze(m2)  =  ml)) 

Specification  3:  CMP  sat  RCMP 

RcMpltrl)  =  V  ml  .(BlackChan.ml  in  Filter(tr1,  BlackChan:M,CipherMode(CMCtl)) 

=>  3m2.(VoiceComsec.m2  in  Filter(tr1  ,VoiceComsec:M, 

CipherMode(CMCtl)) 
a  Modulate(Encrypt(m2,Key))  =  ml)) 

Notice  that  communications  over  VPCtl  are  used  to  determine  whether  the  terminal  is  in  the 
cipher  mode  for  VP,  whereas  communications  over  CMCtl  are  used  for  CMP. 

5.  Prove  the  Concurrent  Restriction  Condition, 

RVp  (trl  I'aVP)  =*  RVP  (trl)  a  RCMp(tr1  I'aCMP)  RCMP(tr1). 

If  this  proof  fails,  revise  the  requirements  so  that  RVP  depends  only  on  the  events  in  the 
alphabet  of  VP  ami  that  Rcmp  depends  only  on  events  in  the  alphabet  of  CMP  and  try 
again. 

We  prove  the  first  conjunct  of  the  Concurrent  Restriction  Condition;  the  proof  of  the 
second  conjunct  proceeds  similarly.  Since  the  only  place  that  trl  is  referenced  in 
Specification  2  of  VP  is  as  a  parameter  to  Filter,  the  first  conjunct  of  the  Concurrent 
Restriction  Condition  follows  from  Theorem  2  below.  This  proof  has  the  same  general 
structure  as  the  proof  of  Theorem  1 . 

Theorem  2: 

(Filter(tr1,  VoiceComsec:M,  CipherMode(VPCtl)) 

=  Filter(tr1  I'aVP,  VoiceComsec:M,  CipherMode(VPCtl))) 
a  (Filter(tr1  ,RedChan:M,  CipherMode(VPCtl)) 

=  Filter(tr1  I'aVP,  RedChan:M,CipherMode(VPCtl))) 

Proof:  We  prove  the  first  conjunct;  the  proof  of  the  second  conjunct  proceeds  similarly.  By 
Lemma  3, 

(VoiceComsec:M  C  aVP 

a  (V  tr2.  tr2  <  trl  =*  (CipherMode(VPCtl)(tr2) 

=  CipherMode(VPCtl)(tr2  I'  aVP)))) 

==> Filter(tr1  I'aVP,  VoiceComsec:M,  CipherMode(VPCtl)) 

=  Filter(tr1 ,  VoiceComsec:M,  CipherMode(VPCtl)) 

->  {Lemma  4,  Definitions  17  of  aVP} 

Filter(tr1  I'aVP,  VoiceComsec:M,CipherMode(VPCtl)) 

=  Filter(tr1,  VoiceComsec:M,CipherMode(VPCtl)) 

End  of  Proof. 

6.  Attempt  to  prove  the  Conjunction  Condition, 

(RVp(tr1)  A  RcMpIFI))  =>  R,iASVT<tr1)- 
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If  successful,  continue  the  tree  traversal  to  the  next  vertex  at  step  3.  Otherwise,  specify  the 
weakest  condition,  C,  needed  to  complete  the  proof 

This  step  is  difficult,  partly  due  to  the  fact  that  the  proof  is  dependent  on  the  proper 
synchronization  of  VP  and  CMP.  We  derive  the  necessary  synchronization  requirement 
through  an  attempt  to  prove  the  Conjunction  Condition.  Analyzing  RVp  and  Rcmp  of 
Specifications  2  and  3  shows  that  the  Conjunction  Condition  can  be  deduced  from  the 
following  theorem: 

Theorem  3:  (Filter(tr1,  VoiceComsec:M,  CipherMode(VPCtl)) 

=  Filter(tr1  ,VoiceComsec:M,  CipherMode(CMCtl)) 
a  Filter(tr1,  BlackChan:M,  CipherMode(VPCtl)) 

=  Filter(tr1,  BlackChan:M,  CipherMode(CMCtl))) 

=>  ((RVp(tr1)  a  RcMP(trl))  =>  RnAsvr(tr1)) 

Proof: 

Filter(tr1,  VoiceComsec:M,  CipherMode(VPCtl)) 

=  Filter(tr1  ,VoiceComsec:M,  CipherMode(CMCtl)) 
a  Filter(tr1,  BlackChan:M,  CipherMode(VPCtl)) 

=  Filter(tr1,  BlackChan:M,  CipherMode(CMCtl)) 
a  RVp(tr1)  a  RCMP(tr1) 

->  {Specification  2  of  RVP  and  Specification  3  of  RCmp} 

V  ml  .(VoiceComsec.ml  in  Filter(tr1,  VoiceComsec:M, 

CipherMode(VPCtl)) 

=s>3  m2.(RedChan.m2  in  Filter(tr1,  RedChan:M, 

CipherMode(VPCtl)) 
a  Analyze(m2)  =  ml)) 

a  V  ml  .((BlackChan.ml  in  Filter(tr1,  BlackChan:M, 

CipherMode(VPCtl)) 

=>  3  m2.(VoiceComsec.m2  in  Filter(tr1 ,  VoiceComsec:M, 

CipherMode(VPCtl)) 
a  Modulate(Encrypt(m2,  Key))  =  ml)) 

{Calculus} 

V  ml. (BlackChan.ml  in  Filter(tr1,  BlackChan:M, 

CipherMode(VPCtl)) 

=>  3  m2.(RedChan.m2  in  Filter(tr1,  RedChan:M, 

CipherMode(VPCtl)) 

a  Modulate(Encrypt(Analyze(m2),  Key))  =  ml)) 

=  {Specification  1  of  R(iAsvt} 

End  of  Proof. 

Theorem  3  states  sufficient  conditions  for  proving  the  Conjunction  Condition. 
Provided  these  conditions  are  true,  when  the  terminal  is  in  the  cipher  mode,  the  origination  of 
a  message  transmitted  through  BlackChan  can  be  traced  through  CMP  from  VoiceComsec. 
Likewise,  the  origination  of  a  message  transmitted  through  VoiceComsec  can  be  traced 
through  VP  from  RedChan.  Unfortunately  we  cannot  prove  the  antecedent  of  Theorem  3 


-20- 


without  additional  information  about  the  valid  traces  of  the  uASVT.  Therefore,  set  C  equal  to 
this  antecedent. 1 1 

7.  Describe  C  as  a  conjunction  of  simple  conditions  in  conjunctive  normal  form.  If  no 
conjunct  depends  solely  on  the  traces  of  either  VP  or  CMP  then  conjoin  C  to  SK,lASVr  and 
continue  the  tree  traversal  to  the  next  vertex  at  step  3.  Otherwise,  conjoin  to  Rp  each 
conjunct  ofC  that  depends  only  on  the  traces  ofP  (for  P  =  VP  or  P  =  CMP )  ami  continue 
at  step  5. 

By  mathematical  induction  on  trl  and  Definition  14  of  Filter,  C  reduces  to  the 
conjunction  of  two  simpler  expressions: 

Condition  C: 

((trl  *  <  >  a  Last(trl)  e  VoiceComsec:M) 

=*•  (CipherMode(VPCtl)(tr1)  =  CipherMode(CMCtl)(tr1))) 
a  ((trl  *  <  >  a  Last(trl)  e  BlackChan:M) 

=*>  (CipherMode(VPCtl)(tr1)  =  CipherMode(CMCtl)(tr1))). 

Recall  that  C\phcvModc(ctlch  I  )(tr  l )  is  true  if  and  only  if  the  terminal  is  in  the  cipher  mode 
after  engaging  in  the  sequence  of  events  trl.  The  mode  is  cipher  if  and  only  if  either  the  most 
recent  transmission  over  ctlchl  was  cipher  or,  if  there  is  no  such  transmission,  the  initial 
mode  is  cipher.  Since  VPCtl  and  CMCtl  are  distinct  channels,  there  is  no  way  to  determine 
the  truth  of  C  from  only  the  definition  of  CipherMode. 

The  truth  of  the  first  conjunct  of  C  depends  only  on  communication  over 
VoiceComsec,  VPCtl,  and  CMCtl;  the  truth  of  the  second  conjunct  depends  on 
communication  over  BlackChan,  VPCtl,  and  CMCtl.  Since  VP  must  participate  in  any  events 
of  trl  that  occur  in  its  alphabet  and  since,  by  Definitions  17  of  aVP, 

Lemma  5:  {VoiceComsec. m,  VPCtl. c,  CMCtl. c 

I  c  e {cipher,  plain},  m  e  M}C  «VP, 

the  truth  of  the  first  conjunct  depends  solely  on  the  traces  of  VP.  Defining  R'Vp  as  this 
conjunct  results  in 

Definition  18: 

R'vp(trl)  =  ((trl  *  <  >  a  Last(trl)  e  VoiceComsec:M) 

=>  (CipherMode(VPCtl)(tr1 ) 

=  CipherMode(CMCtl)(tr1 ))) 

Therefore,  we  can  conjoin  R'Vp  to  RVp.  Unfortunately,  the  second  conjunct  of  C  does  not 
depend  on  the  traces  of  a  single  component.  By  Definitions  17,  communications  over 
BlackChan  and  VPCtl  do  not  occur  in  the  alphabet  of  any  single  component.  Nevertheless, 
since  the  specification  of  VP  has  been  extended,  we  must  go  back  to  step  5  and  reprove  the 
Concurrent  Restriction  Condition  for  VP. 

D.  Justifying  the  Revised  Decomposition 

During  the  first  attempt  to  decompose  the  requirement  of  uASVT,  we  proved  the 
Concurrent  Restriction  Condition  for  the  original  definitions  of  Rcmp  and  RVp.  Conjoining 


1  1  Note  that  since  this  instantiation  of  C  is  not  necessary  to  establish  the  truth  of  the  Conjunction  Condition,  we 
cannot  guarantee  that  the  set  of  synchronization  requirements  derived  is  minimal. 
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R'vp  to  RVp,  requires  proof  that  R'Vp  depends  only  on  the  events  in  the  alphabet  of  VP  to  re¬ 
establish  the  truth  of  the  Concurrent  Restriction  Condition: 

Theorem  4:  R'Vp(tr1  P aVP)  =>  R'VP(tr1 ) 

Proof: 

R'Vp(tr1  P  aVP) 

=  {Definition  18  of  R'Vp} 

(trl  P  aVP  t5  <  >  a  Last(tr1  I'aVP)  E  VoiceComsec:M) 

=>  (CipherMode(VPCtl)(tr1  I'aVP) 

=  CipherMode(CMCtl)(tr1  I'  aVP))) 

->  {Definitions  17  of  aVP} 

(trl  *  <  >  a  Last(trl)  E  VoiceComsec:M) 

=>  (CipherMode(VPCtl)(tr1  I'aVP) 

=  CipherMode(CMCtl)(tr1  I'  aVP))) 

->  {Lemma  4,  Definitions  17  of  aVP} 

(trl  *  <  >  a  Last(trl)  E  VoiceComsec:M) 

=*  (CipherMode(VPCtl)(tr1 )  =  CipherMode(CMCtl)(tr1)) 

=  {Definition  18  of  R'vp} 

R'vpttrl ) 

End  of  Proof. 

Since  RVp  has  been  modified,  the  next  step  is  to  reprove  the  Conjunction  Condition. 
Fortunately,  these  proofs  proceed  exactly  as  before  except,  this  time,  the  proof  depends  only 
on  the  second  conjunct  of  Condition  1.  Since  it  does  not  depend  on  any  one  component  of 
the  uASVT,  the  decomposition  at  this  vertex  is  finished. 

E.  Analyzing  the  Final  Results 

Decomposing  Specification  1  of  uASVT  results  in  a  specification  for  each  component 
and  a  number  of  synchronization  requirements  on  multiple  components.  In  summary,  the 
derived  component  specifications  are  as  follows: 

Specification  4:  VP  sat  RVP 

RVP(tr1)  =  (V  ml.  (VoiceComsec.ml  in  Filter(tr1,  VoiceComsec:M, 

CipherMode(VPCtl)) 

=>  3  m2.  (RedChan.m2  in  Filter(tr1 ,  RedChan:M, 

CipherMode(VPCtl)) 
a  Analyze(m2)  =  ml)) 
a  (trl  *  <  >  a  Last(trl)  E  VoiceComsec:M) 

=>  (CipherMode(VPCtl)(tr1 )  =  CipherMode(CMCtl)(tr1)) 

Specification  5:  CM  sat  RCM 

RCM(tr1)  =  (Vml  .(ModemComsec.ml  in  Filter(tr1  ,ModemComsec:M, 

CipherMode(CMCtl)) 

=>  3  m2.  (VoiceComsec.m2  in  Filter(tr1,  VoiceComsec:M, 

CipherMode(CMCtl)) 
a  Encrypt(m2,  Key)  =  ml)) 
a  (trl  *  <  >  a  Last(trl)  E  ModemComsec:M) 

=>  (CipherMode(CMCtl)(tr1)  =  CipherMode(MPCtl)(tr1)) 
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Specification  6:  MP  sat  RMP 

RMP(tr1)  =  V  ml.  (BlackChan.ml  in  Filter(tr1,  BlackChan:M, 

CipherMode(MPCtl)) 

=>  3m2.(ModemComsec.m2  in  Filter(tr1,  ModemComsec:M, 

CipherMode(MPCtl)) 

a  Modulate(m2)  =  ml)). 

The  first  conjunct  of  RVp  in  Specification  4,  the  first  conjunct  of  RCm  in  Specification  5,  and 
all  of  Rmp  in  Specification  6  represent  the  proper  transformation  of  messages  transmitted 
through  each  component  when  in  the  cipher  mode.  Each  processor  uses  its  own  control 
channel  for  determining  whether  the  terminal  is  in  the  cipher  mode.  At  the  system  level, 
however,  only  VPCtl  is  used  to  determine  whether  the  system  is  in  the  cipher  mode.  As 
suggested  by  the  analysis  of  Sections  IV-C  and  IV-D  this  fact  requires  that  VP  and  MP  satisfy 
additional  conditions,  defined  by  the  second  conjuncts  of  RVp  and  RCm  in  Specifications  4  and 
5.  These  conditions  were  derived  during  the  effort  to  prove  the  Conjunction  Conditions 
during  the  first  and  second  level  decompositions. 

The  second  conjuncts  of  RVp  and  RCm  are  somewhat  obscure.  Their  purpose  is  to 
help  ensure  that  the  position  of  the  mode  selector  dial  is  seen  consistently  by  all  three 
processes.  A  notification  of  a  change  in  mode  for  the  uASVT  requires  the  synchronized,  and 
sequential,  notification  of  each  of  the  three  component  processors  over  the  control  channels, 
VPCtl,  CMCtl,  and  MPCtl.  The  second  conjuncts  form  an  integral  part  of  the  requirement 
that  the  notifications  proceed  uninterrupted  by  message  transmissions.  The  second  conjunct 
of  RVp  states  that  every  mode  change  received  by  VP  over  VPCtl  be  sent  to  CM  over  CMCtl 
before  another  message  is  accepted  for  transmission.  Since  this  is  a  requirement  of  VP  it  is 
stated  as  a  part  of  RVp.  Likewise,  the  second  conjunct  of  Rcm  states  that  every  value  received 
by  CM  over  CMCtl  be  sent  to  MP  over  MPCtl  before  another  message  is  accepted  for 
transmission.  Since  this  is  a  requirement  of  CM  it  is  stated  as  a  part  of  Rcm-  MP  has  no  such 
responsibility. 

Specifications  4  and  5  are  not  sufficient  to  ensure  that  a  mode  change  is  not 
interrupted.  Unfortunately,  this  cannot  be  enforced  merely  by  specifying  requirements  on  the 
component  processes  in  isolation;  two  requirements  on  multiple  components  are  needed: 

Requirement  1: 

(ValidTrace(tr1 ,  (xASVT)  a  trl  ^  <  >  a  Last(trl)  e  BlackChamM) 

=>  (CipherMode(VPCtl)(tr1 )  =  CipherMode(CMCtl)(tr1 )) 

Requirement  2: 

(ValidTrace(tr1 ,  CMP)  a  trl  *<>  a  Last(trl)  e  BlackChan:M}) 

=>  (CipherMode(CMCtl)(tr1)  =  CipherMode(MPCtl)(tr1)). 

These  conditions  are  very  similar  to  the  second  conjuncts  of  RVp  and  RCM.  Intuitively,  they 
state  that  whenever  a  message  is  transmitted  by  BlackChan,  the  current  mode  of  the  terminal 
is  cipher  if  and  only  if  the  most  recent  values  transmitted  over  VPCtl,  MPCtl,  and  CMCtl 
were  cipher,  or,  if  no  values  were  transmitted  over  these  channels,  the  terminal  began  in 
cipher  mode.  The  component  alphabets  given  by  Definitions  17  imply  that  neither  of  these 
conditions  is  the  sole  responsibility  of  a  single  component  of  the  uASVT.  Requirements  1 
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and  2  form  the  set  of  synchronization  requirements  of  the  uASVT  as  referenced  in  the 
introduction  of  this  paper. 

Although  it  is  outside  the  scope  of  this  paper  to  prove  the  requirements  described  in 
this  section,  it  is  interesting  to  look  at  them  in  light  of  the  example  functional  refinement 
presented  in  the  appendix  to  this  paper.  Through  some  analysis  of  these  definitions,  the  truth 
of  Specifications  4  through  6,  and  Requirements  1  and  2,  becomes  apparent.  Proofs  of  the 
component  requirements  are  relatively  easy  to  formalize  using  the  proof  methods  of  the  Trace 
Model  of  CSP.  Unfortunately,  however,  when  one  tries  to  formalize  the  proofs  of 
Requirements  1  and  2,  the  arguments  explode  into  an  extremely  large  number  of  cases,  even 
for  this  relatively  simple  example.  Future  work  requires  determining  methods  for  practically 
dealing  with  such  proofs. 

V.  Summary  and  Conclusions 

This  paper  describes  and  demonstrates  a  method  for  formalizing  and  decomposing 
critical  requirements  of  systems  using  the  Trace  Model  of  CSP.  The  method  proceeds 
iteratively,  until  the  appropriate  requirements  for  the  component  processes  and  the  minimal  set 
of  synchronization  requirements  are  found.  An  extension  to  the  CSP  notation,  involving 
process  composition  with  hidden  internal  structure,  promotes  hierarchical  system  design  and 
decomposition.  A  goal  of  the  decomposition  process  is  to  minimize  the  number  and 
complexity  of  the  synchronization  requirements  since  these  are  the  most  difficult  to  verify  in 
later  system  development.  We  capture  these  requirements  in  the  simplest  possible  context  and 
ensure  that  each  depends  on  the  behavior  of  at  least  two  component  processes.  The  method 
described  reduces  the  problem  of  assuring  that  the  system  meets  its  critical  requirements  to  the 
simpler,  although  possibly  nontrivial,  problem  that  each  component  meets  its  derived 
requirements  and  the  system  satisfies  the  derived  synchronization  requirements. 

Experience  with  the  uASVT  decomposition  confirms  our  belief  that  the  CSP  Trace 
Model  is  a  valuable  formalism  for  specifying  and  reasoning  about  systems  and  their 
requirements.  Although  the  Trace  Model  is  restricted  to  reasoning  about  the  safety  of  non- 
divergent  processes,  within  this  domain  the  power  of  trace  theory  eases  the  description  of 
critical  properties  over  less  sophisticated  models  while  avoiding  the  complexities  of  the  more 
sophisticated  models.  For  example,  the  use  of  separate  channel  histories,  as  in  the  Counter 
Model  and  Gypsy,  complicates  the  statement  of  relationships  between  the  communication 
histories  of  different  channels  at  specific  times  during  a  process's  execution.  The  uASVT's 
Red/Black  separation  requirement  is  difficult,  if  not  impossible,  to  specify  within  this 
paradigm  due  to  the  need  to  determine  the  mode  in  which  the  terminal  is  operating  when 
messages  are  transmitted;  this  determination  requires  finding  out  the  last  value  transmitted 
over  VPCtl  for  each  message  transmitted  over  BlackChan.  The  Trace  Model  allows  the 
statement  of  such  properties  by  describing  process  behavior  in  terms  of  interleavings  of 
distinct  channel  histories.  The  ability  to  decompose  critical  liveness  properties  of  potentially 
diverging  processes  using  the  more  sophisticated  models  is  an  area  of  future  research. 

Stages  of  development,  subsequent  to  system  decomposition,  require  methods  to 
verify  sequential  component  and  synchronization  requirements.  Verifying  properties  of 
sequential  components  does  not  present  any  inherent  difficulties.  Unfortunately,  we  have  not 
yet  found  a  practical  approach  applicable  to  nontrivial  systems  for  formally  proving  the 
derived  synchronization  requirements.  Although  proof  methods  for  reasoning  about  global 
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properties  exist  within  the  CSP  Trace  Model,  they  are  intractable  for  most  real-world 
systems.  This  problem  is  not  unique  to  the  model  used  here;  the  other  models  of  CSP 
discussed,  as  well  as  the  proof  methods  of  Gypsy,  exhibit  these  same  difficulties.  In  general, 
if  it  is  impossible  to  derive  component  process  requirements  that  are  sufficient  to  prove  the 
system  requirements,  reasoning  about  global  properties  is  required.  This  condition  arose  in 
the  decomposition  of  even  the  relatively  simple  uASVT  example  as  discussed  in  section  IV. 

The  EHDM  verification  system  [8]  is  proving  useful  for  mechanically  checking  the 
proofs  required  of  the  decomposition  process.  We  have  encoded  within  the  logic  of  EHDM 
the  relevant  portion  of  the  CSP  Trace  Model  allowing  system  architecture  and  requirements  to 
be  specified.  Directed  by  an  informal  proof  outline  derived  separately,  we  can  guide  EHDM 
through  the  seven-step  method.  When  applied  to  the  uASVT  decomposition,  EHDM 
supplied  many  of  the  low-level  proof  details,  e.g.,  variable  instantiations,  and,  at  times, 
caught  errors  in  the  informal  proof.  The  final  EHDM  proof  provided  necessary  information 
for  revising  and  refining  the  informal  proofs.  This  paper  presents  a  subset  of  these  revised 
proofs. 

Although  the  use  of  EHDM  is  beneficial  towards  checking  the  integrity  of  a 
decomposition,  it  is  clear  that  the  availability  of  tools  specifically  oriented  towards  specifying 
and  verifying  systems  involving  concurrency  are  needed  to  facilitate  the  decomposition 
process.  Verification  systems  with  much  of  the  concurrency  model  built  in  would  allow  the 
automation  of  large  portions  of  the  proof  process.  Alternatively,  verification  systems  that 
allow  the  user  to  define  automatically  invoked  decision  procedures  would  permit  developers 
to  "program"  the  theorem  prover  with  CSP-specific  proof  strategies.  Experiences  such  as 
those  described  in  this  paper  may  prove  beneficial  for  identifying  useful  characteristics  of 
verification  tools  and  helpful  decision  procedures  for  verifying  concurrent  systems. 

The  decomposition  method  proposed  in  this  paper  applies  to  systems  with  critical 
requirements  implemented  in  either  hardware  or  combinations  of  software  and  hardware. 
Executable  languages  supporting  concurrency  [43,44,45]  may  be  useful  for  prototyping 
systems  described  in  CSP  [46,47,48],  for  testing  the  validity  of  formalisms  specified  in  the 
Trace  Model  [49],  and  for  continuing  the  formal  verification  to  lower  levels  of  system  design 
and  implementation  [43].  Others  are  investigating  the  incorporation  of  CSP  into  formal 
methods  that  do  not  explicitly  deal  with  concurrency  such  as  the  Z  specification  language  [4]. 
If  decompositions  are  taken  to  a  sequential  level,  more  conventional  procedural  languages 
may  be  used  to  implement  systems  in  software  or  as  design  languages  for  hardware.  Formal 
reasoning  can  proceed  in  such  languages  if  a  trace  semantics  can  derived  for  programs 
written,  e.g.,  [39].  Since  our  method  focuses  on  requirement  decomposition  rather  than 
physical  decomposition,  it  can  be  used  during  structural  hardware  design  to  decompose 
requirements  for  hardware  in  a  top-down  fashion  as  primitive  hardware  elements  are 
interconnected  to  realize  higher-level  blocks  in  a  bottom-up  fashion. 

Decomposing  requirements  using  formal  methods  enhances  the  role  of  testing  and 
simulation  in  the  design  of  trustworthy  systems.  A  designer  tests  a  system  description  to 
determine  whether  it  meets  the  requirements.  Complex  systems  lead  to  complex  test  suites. 
The  greater  the  complexity  of  the  test  suite,  the  more  difficult  it  is  to  determine  whether  the 
system  meets  its  requirements.  A  requirement  decomposition  allows  the  designer  to  break  the 
test  suite  for  a  system  into  smaller,  less  complex  test  suites  for  its  components.  This 
simplifies  the  requirements  that  must  be  assured  and  decreases  the  number  of  execution  paths 
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that  must  be  traversed.  Simplifying  the  testing  process  in  this  way  increases  the  probability 
of  finding  problems  that  exist  in  the  design.  Of  course,  each  synchronization  requirement 
derived  from  a  requirement  decomposition  requires  testing  of  those  components  on  which  it 
depends. 

Further  work  is  proceeding  along  two  complementary  lines:  the  application  of  the 
decomposition  method  to  a  security-critical  portion  of  a  full-scale  communication  system  and 
the  extension  of  the  method  to  handle  the  verification  of  the  component-level  and 
synchronization  requirements.  From  derived  component-level  requirements,  we  expect  to 
generate  and  verify  implementations  of  the  components  using  some  formally  verifiable 
programming  language  such  as  Gypsy  [29]  or  m-Verdi  [50].  Unfortunately,  due  to  the 
immature  state  of  formally  verifiable  languages,  the  actual  source  code  will  likely  be  written 
in  a  more  conventional  language  with  better  run-time  support.  Nevertheless,  the  verified 
implementations  will  act  as  low-level  functional  descriptions  from  which  to  derive  the  source 
code.  Using  strict  coding  conventions  and  review  procedures  this  derivation  should  be  fairly 
straightforward  so  as  to  preserve  the  formal  verification  accomplished  at  the  higher  levels. 
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Appendix:  A  CSP  Implementation  of  the  qASVT 

The  following  functional  description  reflects  the  operation  of  the  terminal  as  discussed 
in  Section  IV.  Note  that  the  CSP  recursive  process  iiX.F(X)  represents  the  process  X  such 
that  X  =  F(X).  The  choice  process  (el  — >  P)  I  (e2  —>  Q)  represents  a  process  that  first 
engages  in  either  el  or  e2.  If  it  engages  in  el  then  it,  subsequently,  behaves  like  P;  if  it 
engages  in  e2  then  it,  subsequently,  behaves  like  Q. 

VP  =  VPCtl  ?  mode 

—  pY.(CMCH !  mode 

-*  if  mode  =  cipher 

then  |iX.  ((RedChan  ?  msg  ->  VoiceComsec  !  Analyze(msg)  -» X) 

I  VPCtl  ?  mode  —  Y) 

else  liX.  ((RedChan  ?  msg  -»  VoiceModem  !  Analyze(msg)  -*  X) 

I  VPCtl  ?  mode  —  Y)) 

CM  =  CMCtl  ?  mode  -> 

—  uY.(MPCtl !  mode 

-*  if  mode  =  cipher 

then  (xX.  ((VoiceComsec?  msg  -»  ModemComsec  !  Encrypt(msg,  Key)  -»  X) 

I  CMCtl  ?  mode  —  Y) 
else  CMCtl  ?  mode  -*  Y) 

MP  =  MPCtl  ?  mode 

-» fxY.(if  mode  =  cipher 

then  nX.  ((ModemComsec?  msg  ->  BlackChan  !  Modulate(msg)  -*  X 
I  MPCtl  ?  mode  -*  Y)) 

else  n-X.  ((VoiceModem  ?  msg  ->  BlackChan  !  Modulate(msg)  X) 

I  MPCtl  ?  mode  —  Y) 
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